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We introduce the notion of nonuniform coercion, which is the promotion of a value of one type 
to an enriched value of a different type via a nonuniform procedure. Nonuniform coercions are 
a generalization of the (uniform) coercions known in the literature and they arise naturally when 
formalizing mathematics in an higher order interactive theorem prover using convenient devices like 
canonical structures, type classes or unification hints. We also show how nonuniform coercions can 
be naturally implemented at the user level in an interactive theorem prover that allows unification 
hints. 



1 Introduction 



In type theory, a coercion is a function k of type S—?-T that can be automatically inserted by an interactive 
theorem prover to promote a value v of type S to a value k v of type T whenever v is used in a context 
where it is expected to have type T. The typical example is the promotion of natural numbers to integers. 

In a theory with dependent types coercions are better generalized to couples (k,n) where k is a 
function of type ELc/ : S ; -(jci , . . . ,jc;-i) .^(jci , . . . ,x m ) and n < m is the index of one of the arguments 
of k. The coercion is automatically inserted to promote a value v of type S(t\, . . . ,t n -i) to a value 
kt\ ...t n -\vt n+ \ . . . t m of type T (t\ , . . . , t m ) . The arguments t\ , . . . , t n -\ , t n+ \ , . . . , t m are partially inferred 
from the actual type of v or from the expected type; those that are not inferred become proof obligations 
for the user. The typical example for the latter situation is the coercion from lists to non-empty lists, that 
opens a new proof obligation for the non-emptiness of the argument. This kind of parametric coercions 
have been heavily exploited by Sozeau in the Russell language iTToTl . 

All the previous examples of coercions are uniform in the sense that, up to the inferred arguments, 
the very same function k is used to promote the value v. For instance, if k is the promotion from natural 
numbers to integers, 3 and 5 are promoted respectively to k 3 and k 5. Nevertheless there are situations 
where we would like to promote v in a non uniform way, depending on the actual value of v, but the 
language does not allow one to inspect (i.e. pattern match over) v, only the meta-level allows it. 

For example, consider the promotion of a type (the carrier of a semi-group) to a semi-group (the 
carrier enriched with the operation). Different types are associated (even not uniquely) to different semi- 
groups on them: the type N of natural numbers could be promoted to the semi-group (N,+) whereas 
the type List N could be promoted to (List N, @) (where '@' is the append operation). Since no 
function in type theory can distinguish between N and List N, there is no uniform coercion of type 
Type — > SemiGroup that behaves in the expected way. 

As far as we know, nonuniform coercions have not been considered so far in the literature. Neverthe- 
less, they arise quite naturally when devices like canonical structures [9], type classes [17] or unification 
hints [3] are employed. 

In Sect. [2] we introduce a syntax and semantics for nonuniform coercion declarations and in Sect. [3] 
we present the use of nonuniform coercions as a complementary device to canonical structures like 
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mechanisms. In Sect. [4] we recall the syntax and semantics of unification hints [ 3 ] . In Sect. [5] we show 
how nonuniform coercions can be efficiently implemented at the user level in an interactive theorem 
prover equipped with a flexible coercion system and unification hints. Sections [6] and [7] are devoted to 
the solution of two different problems that naturally arise when nonuniform coercions are employed. 
Conclusions and future works follow in Sect. [8] 



2 Syntax and semantics 

Let r be a well-typed context, i.e. a sequence of variable declarations of the form xt : /?, where each 
Ri is a well typed type in the context x\ : R\ . . -Xi-\ : Ri-\. A nonuniform coercion declaration has the 
following syntax: 

|_ S\ — > T\ p | Sn y T n 

1 1 h ... L n h 

Sl !->■ t\ S n H-> 

where each Sj has type Sj in r ; ; each tj has type 7]- in T,-. 

Promotion works as follows: let s be a term of type S which is expected to have type T and let a be a 
substitution that instantiates the variables declared in T, and such that SjG = s and 5 ; a = S and 7}<7 = T . 
Then ^ can be promoted to ?,a of type f. 

Operationally, the substitution a is determined by looking for the smallest index i such that a is the 
most general unifier of Sj with s, of Sj with 5 and of 7} with f . The substitution a can be made total by 
instantiating every still uninstantiated variable x ; : Rjo with the result of a proof obligation for RjO. 

Instead of stopping at the first index that yields a result, it could also be possible to try all of them 
and let the user interactively choose the desired promotion. Stopping at the first index is often desirable 
since it allows one to add overlapping branches ordering them by number of open proof obligations (see 
Example [3] below) . 

Example 1 (Uniform coercions) A uniform coercion (k,n) where 



k-.Tlxi: S i (xu...,x i -i).T(x 1 ,...,x m ) 
is equivalent to a nonuniform coercion 

. c ( \ I S n (x\ , . . . ,Xn— i ) y T (X\ ) . . . j X m ) 

. . .Xi . Oj(JCi, . . . ,Xi—\) ■ ■ ■ r , 

JCyi I t K> X J ... -Xfii 

Conversely, every branch of a nonuniform coercion whose pattern Sj is a variable x n is equivalent to a 
nonuniform coercion: 

. c r \ I S n (x\, . . . ,x n -\) —> T(xi,...,X m ) 

. . .A; . Oj^Jti, . . . iM—\) ■ ■ ■ ' . . 

Xij I r t 



is equivalent to the uniform coercion (Xxi : Si(xi, . . . ,Xi-i).t,n): 



Xxj : Si(x\,...,Xi^i).t : Ylxt : Si(xi,...,Xi-i).T(xi,...,x, 
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Example 2 (Structure enrichment) Let K be a proof of the associativity of + over Z and n a proof of 
the associativity of the append operation over lists. 

Type — > SemiGroup Type — > SemiGroup 

Z h-> (Z, +, rc) : yPC ListX (ListX, @X, 7lX) 

A^ote ?/za? f/ze second coercion is polymorphic in the type of the list arguments. Seen as two independent 
uniform coercions, the two coercions are incoherent HI IV since they both promote from and to the same 
couple of types and they are not a/3 rj -convertible. 



Example 3 (Property enrichment) Let nbea proof that + is associative, AssocFun the structure of as- 
sociative functions and assoc_comp a proof that the composition of objects in AssocFun is in AssocFun. 



N-^N-^N —j- AssocFun N 



X : Type,* :X ->X ->X, X^X^X ->■ AssocFun X 

p :\/a,b,c : X.a* (b*c) = (a*b)*c * \-t {*,p) 

X : Type,/, g : AssocFun X h 



X-^X->X -> AssocFun X 
fog \— )■ assoc_comp/g 



used to promote + ?o an associative operation, no proof obligation is left open. On the other 
hand, when used to promote * : N — > N — > N to an associative operation, the user is left with the proof 
obligation p : \/a,b,c : N.a* (b*c) = (a*b) *c. Finally, the composition of two associative operations 
is promoted to an associative operation applying the theorem assoc.comp. The third case can not be 
expressed as a uniform coercion since the pattern is not a variable. 



3 Nonuniform coercions for mathematical structures 

Different ITPs provide the user different devices to fill the gap between the high level language used 
to reason about abstract and complex mathematical theories and the drastically lower level foundational 
language understandable and checkable by a computer. 

Among the most widespread machineries to aid the user we mention decision procedures; general 
purpose proof searching facilities, usually by means of external tools; model checkers and SMT solvers. 
All these tools usually fall in the category called, with some abuse, automation. Even if these tools 
shown to be quite effective in many areas, some radically different techniques were recently successfully 
employed 0[9j[5l[T8l to a id the user in systems based on higher order languages. 

Canonical structures, type classes (and their generalization into unification hints) allow the user to 
instrument the ITP linking objects and properties by means of structures. Structures pack together axioms 
that give rise to a theory and that are used to quantify theorems (i.e. once defined the structure Group 
packing together the group axioms, theorems about groups have usually the shape VG : Group, . . .). The 
user is then asked to link models of these structures to their characterizing structure, so that the ITP is able 
to exploit such link when needed. For example, once proved that integers Z together with addition +, 
and the inverse — form a group 3?, every theorem that holds on groups can be used over expressions 
laying in the signature (Z, +,— ,0), even if the group structure 5° is not mentioned in any way in the 
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context of the current conjecture. In addition to that, limited forms of Prolog like proof search allow the 
ITP to infer derived structures given the basic ones. For example, the pair (0, 0) can be transparently 
considered as the unit of the Cartesian product group 3? x given the general result that the Cartesian 
product of groups forms a group. 

These forms of inference, although not as general as other automatic devices, tend to be more pre- 
dictable and allow the user's formalization and proof strategy to be closer to the widespread and natural 
mathematical argument: since X together with Y form a Z, we have P(X,Y). Moreover they shown to be 
very effective in building reusable libraries of formalized mathematics |9l. 

3.1 Mathematical structures in dependently typed languages 

We briefly review here how the aforementioned devices are implemented in an interactive theorem prover 
based on an higher order and dependently typed language. 

Suppose that the system library contains the definition of natural numbers N, of multiplication over 
them and the proof that multiplication is associative, commutative and it has a neutral element. Suppose 
also that the library contains the definition of unital semigroups (i.e. semigroups that have a left neutral 
element), represented as a dependently typed record lTT4l[T5l : 

UnitalSemiGroup := 

{S : Type; 1:5; * : S — > S — > S; %: is_unital_semi_group SI*} 

The record projection 5 is declared as a uniform coercion of type 

UnitalSemiGroup — > Type 

so that a quantification over a unital semigroup G is automatically promoted to a quantification over the 
group carrier (S G) . 

The library contains all the interesting theorems of the theory of unital semigroups, stated by making 
the quantifiers range over dependently typed records. One example is the unicity of the neutral element, 
if it exists: 

VG : UnitalSemiGroup. Vx : G.(Vy : G.y *x = y) =>■ x = 1 

Suppose now that the user, during a proof over natural numbers, knows the hypothesis Vy : N.y + x = 
y (let's call it H) and she needs to conclude that x = 0. In order to do that, she wants to apply the 
unicity property of the neutral element of a unital semigroup, that is she wants to feed the hypothesis 
Vy : N.y + x = y to the theorem L that proves the unicity and that expects a unital semigroup G, an x in 
the carrier of G and a proof that Vy : G.y + x = y. The action of invoking the lemma L generates the 
unification problem 

7 

Vy : G.y*x = y = Vy : N.y + x = y 

that can be solved by choosing for G any unital semigroup over the natural numbers whose operation is 
addition. The system automatically picks the right group definition if the user has already instructed the 
system (by means of canonical structures or with the more flexible mechanism of unification hints) to 
always enrich N to (N,0, +,...) under the previous constraints. 

More formally, the user has fed the system with the request to apply the proof term LIqxH where 
?G is a metavariable to be instantiated by unification and the unifier instantiates ?q with (N,0, +,...). 
Note that no coercion has been applied in this case: ?g is identified by the system since it occurs in the 
type of x and H, which are known. 
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Most of the time, the previous mechanism is sufficient to perform the enrichment. Nevertheless, there 
are situations where the enriched structure to be discovered does not occur dependently in the type of 
some other parameter (or in the expected conclusion). For instance, suppose that we already know that 
the exponential function is injective and suppose that we want to inhabit the type (injectiveFun M M) 
of injective functions over real numbers with the function Xx.e e * . Since the previous A-abstraction is just 
a type theoretic function from M to M, what we need here is an automatic promotion of the function from 
(R — > R) to (InjectiveFun R R), which can be achieved by means of a nonuniform coercion similar 
to the one in Example [3] that states that the composition of injective functions is injective. 

Without nonuniform coercions, the user is obliged to manually feed the system with the enriched 
structure itself, as in a traditional procedural language. This is, for instance, what happens currently 
in J9), where two distinct mechanisms (and notations) are used to enrich structure when the canonical 
structure mechanism is not triggered. The simplest one overloads every notation defining a scope for 
every possible enrichment. Then, the explicit scope delimiter can be used to interpret the notation as 
desired by the user. For example the construction APiB, even if A and B are groups, returns a set, 
while (AflB)%G returns a group. This mechanism does not only force to redefine every notation for 
every structure, but has also some technical limitations that make it fail if one among A and B is not 
explicitly typed as a groupQ The second mechanism is way more verbose, but does not suffer from the 
aforementioned limitations, and is thus used as a fall back for the former. To enrich G to the wanted 
structure the user types "[the structure of G]" and a rather complex machinery generates behind 
the scenes an ad-hoc unification problem that triggers canonical structures inference. 
Note that in both approaches what the users types is what will then be displayed, thus the more verbose 
an enrichment notation is, the more cluttered the lemmas statements and the intermediate goals of their 
proofs will be. 

In the next section we see that, quite surprisingly, nonuniform coercions can be implemented for free 
at the user level in a system based on dependent types and unification hints. 

4 Unification hints in a nutshell 

Unification hints @ give solutions to (higher order) unification problems that fall outside the domain 
of the regular unification heuristic implemented by the ITP. They are presented as rules of the following 
form: 

^ •= # 
Th 'p'-Q m yhint 

where: 

1. r is a context that declares meta- variables ? y ; 

2. ?jc := it is a telescope of definitions for metavariables undeclared in T; 

3. all meta-variables in P and Q are declared in T or defined in the telescope; 

4. P = Q is a linear pattern in the meta-variables defined in the telescope (i.e. every meta- variable l x 
occurs just once either in P or in Q); 

'This phenomenon happens, for example, when B is a local definition for C(1D. Unfolding B and then forcing the groups 
scope would make all instances of n to be interpreted at the group level, but if B is not manually unfolded, only one occurrence 
of n is affected by the scope delimiter, thus the full expression fails to be enriched. 
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5. the type checking rules for meta- variables mimick the corresponding rules for variables; all the 
terms in T, 7l , P and Q must be well typed. We use meta-variables since we expect them to be 
instantiated by unification^] 

A hint is acceptable if T \- P[lt /l x ] = Q[lt i.e. if the two terms obtained by telescopic sub- 
stitution, are convertible in T. Since convertibility is (typically) a decidable relation, the system is able 
to discriminate acceptable hints. As a consequence, for every substitution a that instantiates only meta- 

9 

variables in T, all unification problems of the form Pa = Qa can be solved by the unifier p that assigns 

to each ? v the term Ha. As a generalization, if T is a generic meta-variable substitution, all unification 

; ► 

problems of the form Px = Qx can be solved by recursively solving the new problems l x x = Hx (whose 
solution is p in the simple case where x behaves as the identity function on the meta-variables in the 
telescope). 

Unification hints are triggered in case of a unification failure. If the failing problem is P = Q, the 
system looks for an hint such that there exists a unifier x of P with P an d Q with Q, and then try to solve 

the unification problem by triggering the recursive problems l x x = Hx. 

When there are multiple hints matching the failing unification problem, the system can either ask 
the user about the desired one, or it can pick the first matching hint according to some user defined 
precedence level (e.g. in order of declaration or by more precise matching). 

We give a bird's-eye view on how they allow one to apply a simple property of groups in a context 
where the group structure is implicit. Consider the following statement and its corresponding form 
without (part of its) notational sugar. 

a + = a zplus a = a 

where a is a point in Z. The group theoretical property we want to apply is the right-identity law for + 
and that is 

gr id : VG : Group, \/x : carr G,op G x (unit G) = x 

Instantiating this axiom to a and leaving G implicit (i.e. considering the term grid ?q a ) triggers the 
unification problem carr ?g = Z, since a : Z is expected to have type carr ?g- This problem can be 
solved only by guessing a model of a group whose carrier is the set Z. 

Similarly, if we use grid to perform the rewriting without instantiating it first (i.e. we use the term 
grid ?g ?x with an expected type whose left hand side is zplus a 0), we trigger the unification problem: 

op ?g ?je (unit ?g) = zplus a 

If the unification goes from left to right, the system must unify op ?q with zplus; if it goes from 
right to left, it must unify unit ?g with 0. In both cases we are facing again an unification problem 
where a projection (op, unit or carr) is applied to an implicit structure ?g and a model of the structure 
must be guessed by the system. Since any guess would be arbitrary and could involve proof search, we 
expect the system to fail. 

To force a solution to the unification problem, the user can specify the following hints that link the 
carrier Z, the operation zplus and the constant to the group structure 3f. 

2 Due to type dependencies, it is not always possible to give all the meta-variable declarations first (in T) and then all the 
meta-variable definitions. Interleaving declarations and definitions poses no problem (and we implicitly assume that it is done). 
Nevertheless, we prefer to present the hints in this way for clarity purposes. 
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?. := 2T ?. := ?. := jT 

I 1 I 

carr ? g = Z op ? g = zplus unit ? g = 

Unification hints can also be used to drive proof search with clauses that resemble the ones used in 
logic programming. For instance, to solve the problem 

carr ?i = Z x Z 

the user can declare the following hint that recursively reduces the problem to simpler ones: 

, ?A:=carr? /t 1 B := carr \ ? g :=? /i x? g 

> h , > q . Group h _ 

carr? g =? A x? B 

Intuitively, the hint says that, if the carrier of a group ? g is a product ?a x ?b, where ?a is the carrier of a 
group ?/, and ?# is the carrier of a group ? q then a solution consists in choosing for ? g the group product 
of l h and l q . 

4.1 Hints and coercions indexing 

Another view at unification hints is that they define equivalence classes of convertible terms that are 
considered indistinguishable by every functionality of the system that works up to unification. Promotion 
of terms via (uniform) coercions is the typical example: if the user declares a coercion from Z to Q, we 
expect the system to be able to promote also carr 3? to Q. 

This behaviour, however, does not come for free. Consider a failing unification problem P = Q. 
In order to retrieve a coercion from P to Q, it would be inefficient to iterate over the whole set of 
coercions to find the ones that goes from M to N such that M unifies with P and N unifies with Q. 
The usual implementation strategy is to use a discrimination tree lfl2l [T3l (or discrimination nets) to 
index the coercion and perform a quick approximated search. These data structures, born in the field of 
automatic theorem proving, are first order oriented and compare terms according to their rigid structure. 
For example (carr 3T) and Z would be considered different for at least two reasons: both their head 
constant and head function symbol arity differ. 

Thus, in order to retrieve coercions up to hints, the system must do some additional work, for instance 
to index every coercion multiple times (on all M' and N' such that M and M' are in the same hint-induced 
equivalence class, and the same for ,/V and N'), or to perform the search multiple times (for every P' and 
Q' such that P and P' are in the same hint-induced equivalence class, and the same for Q and Q'). 

In the rest of the paper we assume our system to implement both unification hints and retrieval of co- 
ercions up to unification hints. The Matita interactive theorem prover (Hill satisfies these requirements. 



5 Non Uniform Coercions via Unification Hints 

We analyze at first a particular scenario where it is easier to explain the ideas involved. Suppose that we 
are interested in implementing the following nonuniform coercion with two branches: 

S -> T S -> T 

S[ i — y t\ 5^2 i — > t% 

The simplified scenario is characterized by the fact that all branches are uniform in the types S and T; 
the fact that we consider just two branches and that we analyze only the case where all contexts T,- are 
empty is just to simplify the presentation and dropping these two limitations poses no real problem. 
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Suppose also, to grant the coherence of the coercion graph, that the system only allows one to declare 
a single uniform coercion between two given (equivalence classes of) types. The only way in which a 
single uniform coercion can present the expected non uniform behaviour is that it takes in input: 

k : VS : Type.S -»• Vr : TypeT -»• T 
kSsT t:=t 

so that s\ can be promoted to k S si T t\ and S2 can be promoted to k S S2 T t2- However, when a term s 
of type S is expected to have type T, according to the standard semantics of uniform coercions, the user 
will be presented with a proof obligation of type T and the term s will be promoted to k S s T t (that 
reduces to t) where t is the proof term provided by the user in the proof obligation. This means that the 
coercion maps any term of type 5 to a term of type T after asking the user what term must be chosen. 
Instead, we would like the system to automatically pick t\ for t when siss\, to pick t2 for t when s is S2 
and to fail in all the other cases, without bothering the user at all. 

The idea to achieve the expected result is to use unification hints to automatically suggest the term 
t. However, unification hints are only triggered in case of a unification failure and apparently the only 
failing unification problem is the initial one: S = T where s and t do not occur at all. 

5.1 Lifting terms to types 

In a dependently typed language, terms can occur in types, or better can be lifted to types when they 
occur as arguments of a dependently typed function. 

The trick we employ is to declare the nonuniform coercion not from S to T, but from S to a type that 
is convertible to T but that exposes s and t. We can make a first shot with the following definitions: 

force : VS : Type.S -»• Vr : TypeT -> Type 
force S s T t :=T 

The force type has the property that force S s T t is /3 -equivalent to T. The coercion k is now redefined 
as follows: 

k:\fS: Type.Vs : S.VT : Type.V? : T.f orce SsTt 
kS sT t :=t 

With these definitions, when a term s of type S is used with type T, the system tries to promote s to 
kS s?t It (which reduces to ?,) yielding a new unification problem 

_ ? 
force S slj l t = T 

In this unification problem we have both s and ? f , and so we have the data for choosing a term for l t in 
function of s. Moreover, since l t is also the argument the coercion k is returning, the solution for the 
unification problem can define the output of the coercion. 

However, we also have that the left hand side reduces to ?r and thus the system can easily solve 
the unification problem by choosing T for ?j, without using any unification hint at all and, once again, 
opening a proof obligation of type T to determine the unconstrained term ? f . 

5.2 Locked reduction and lockpicking via hints 

In order to solve the problem, we need to change our definition of k (and force) again in order to 
produce in a similar way a new unification problem whose solution is too difficult to be found by the 
system without resorting to unification hints. 
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In other words, we need to change the definition of force in such a way that (force S s lj ?;) is no 
longer always reducible to lj, but only in certain user-defined situations. 

The latter behaviour can be achieved by adding an additional parameter to force that must take a 
precise value to unlock the good reduction. This can be achieved in many ways, one of them being 
to parameterize force over an inhabitant of the unit type and using pattern matching on it to block 
reduction until the canonical inhabitant is passed: 

force : VS : TypeS -»• Vr : TypeT -> 1 -> Type 
force S s T t lock := match lock with [ * =>■ T ] 

The force type has the property that (force S s T t *) is /3 -equivalent to T (where ★ is the canonical 
inhabitant of 1), but reduction of (force S s T t ?;) is blocked. The coercion k is now redefined as 
follows: 

k:\fS: Type.Vs : S.VT : Type.V? : T.l -»• force SsTt 
k S s T t lock := match lock with [ * =>■ t ] 

The system now tries to promote s of type S to (k S s lj ?i ?/) that generates the new failing unification 
problem 

9 

force 5 5 ?r ?( ?/ = r 

At last, this is where the unification hints come into play. Indeed, we can define the following two 
acceptable unification hints: 

? r := T 1 T :=T 

I I 

force S s\ It ?f ?/ = T force S S2 ?r ?r ?/ = T 

that suggests respectively the solution t\ when *i is matched and the solution tj when S2 is, unblocking the 
reduction by fixing ?/ to be ★ so that (force S Si T U ★) reduces to T and the promoted term (A: 5 j ; - T ti ★) 
reduces to as expected. 

5.3 The general solution 

The simplest scenario of the previous section assumed every branch of the nonuniform coercion to go 
from S to T. The assumption was necessary to type the very first failing attempts. However, it is useless 
for the final working solution presented at the end of the section and thus it can be dropped. Similarly, 
the number of branches in the nonuniform coercion also plays no role since it just corresponds to the 
number of unification hints to be declared. Also the order in which the branches are listed (and that 
determines the branch that is triggered when multiple branches can) can be preserved by defining the 
unification hints in the good order (or by giving an explicit precedence to them). Finally, branches with 
a non empty context T, also pose no problem since unification hints are also parameterized by a context. 

Thus, to summarize, the final general solution is the following. First of all, we declare at the begin- 
ning of the library the definition of force and k 

force : VS : Type.5 -> Vr : TypeT -> 1 -»• Type 
force SsTt lock := match lock with [ * =>- T ] 

k-.yS: Type.Vs : S.VT : Type.V? : T.l -»• force SsTt 
k S s T t lock := match lock with [ * =>■ t ] 



C. Sacerdoti Coen & E. Tassi 



25 



and we declare k as the only (uniform) coercion. Then, to declare a nonuniform coercion whose branches 
are all of the form 

r h Si -> Ti 
Si i-> fj 

the user declares for each branch the following acceptable unification hint: 

force 5; 5; ? r ? t ?/ = 7/ 

where T- is obtained from r, by turning every variable x in a meta- variable l x , and the same holds for T(, 
5- and s- and t[. 

Of course, the system could just implement the standard syntax for nonuniform coercions as syntactic 
sugar for the unification hint itself. 

In particular, since only one uniform coercion (k) is declared, the ITP code that implements coercion 
can be simplified, for example dropping all optimizations for fast indexing/retrieval. Actually, since the 
coercion k must be able to promote any type to force, the ITP must allow the declaration of coercions 
going from any type to something. This feature can be considered quite unusual since it does not allow 
any form of efficient indexing. For instance, the Coq system would not accept k as a coercion. Matita, 
instead, does not have this restriction. In any case, with a bit of work, we can avoid the limitation when it 
is there by redeclaring k multiple times as a coercion from T to force for every type T whose elements 
can be promoted. 

Remember that, in our implementation of nonuniform coercions via unification hints, we have as- 
sumed the ITP to only allow a coherent set of uniform coercions. With our implementation, uniform 
coercions can now be handled as special cases of nonuniform coercions, with the side effect of having 
the possibility to declare incoherent sets. Incoherence is then handled for free by systematically choosing 
the first matching hint (or the one with the greatest priority). 



6 Reasoning about Curryfied morphisms 

During the last year the Matita ITP was redesigned, and one of the novelties was the introduction of 
unification hints to support the mathematical structures technique. Even if the old system (version 0.5.x) 
was lacking any kind of structure inference support, we formalized with it a hierarchy of algebraic and 
topological structures. It was clear that porting this formalization to the new system embracing the 
mathematical structures approach was a good test bench. The following example, extracted from the 
formalization mentioned above, convinced us to study the notion of nonuniform coercions presented in 
this paper. 

The setting of the formalization is deeply extensional: points belongs to types equipped with an 
equivalence relation, usually called setoids. Functions respecting the equivalence relation of their source 
and target types are called morphisms and are denoted with A =>- B where A and B are setoids: 

setoid := { T : Type; ps: T — > T — > Prop; n~ : is_equiv_relation T ps } 
A=>B := {f:A^B;n f : Vx,y :A.x^ A y^fx^ B fy} 

One may expect that the concept of unary morphism extends in a straightforward way via currying 
to n-ary morphisms as the concept of unary function extends, in an higher order languages, to n-ary 
functions. This is not the case for morphisms, since currying comes at an extra price: in order to form 
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A =>■ (B =>• C) , the target B =^ C must be a setoid, while B =>• C is a type. We can obtain a setoid of carrier 
B =>• C equipping the carrier with the following extensional equality relation over morphisms: 

A,B : setoid; f,g:A=>B\-f g := Vx : A./x ~b g x 

so that (B =>- C, BC, . . .) is a setoid (that we denote as B C). It is now possible, but cumbersome 
and distracting, to write a currified morphism as A (B C). A much better solution is to exploit the 
following nonuniform coercion to allow the implicit promotion of B =>■ C to B C: 

. , „ . , Type — > setoid 

A : setoid, B : setoid h , . „ . 

A=^-B !->■ (A =^B,p^,tt^) 

where is a proof that «^ is an equivalence relation over morphisms. 

Before developing the concept of non uniform coercions we tried other solutions, but they turned out 
to be quite unsatisfactory. 

First, note that a uniform coercion cannot distinguish the type A =>- B from another type, thus would 
apply in unexpected contexts too. 

It would be also hard to achieve the same result relaying on the notational support the interactive 
theorem prover offers to overload the =>- and notations. Indeed, in the very same expression A =>■ 
(B =>■ C) the first occurrence of is intended to define a morphism, while the other occurrence must 
define a setoid, but interpreting all the occurrences as setoids, possibly inserting a projection in front, 
makes sense too (even if it is not the intended meaning). This approach would thus require the system to 
employ a non trivial mechanism to disambiguate notational overloading. 

Last, it is always possible to define different record types for unary, binary, etc. morphisms, but it 
turns out to be rather inconvenient as soon as one has to reason about partially instantiated morphisms. 
For example a partially instantiated binary morphism of type A =>■ B =>- C would have type B — > C, 
since functions belonging to that morphism class have type A — > B — > C and not A — > B C. The real 
shortcoming is not that the system has to enrich partially instantiated morphism, but that the user has to 
link every n-ary morphism to n — 1 possible enrichments (and all of them comprise a different proof for 
the 71/ component of the morphism structure). 



7 Lifting types, not notations 

Every ITP allows some degree of user configurable notational support. Consider the following conjecture 
(where we used the respectively infix notation + for addition over integers and prefix notation — for 
inverse) 



x,y : Z<r x + -(y+x) = -y 

and the following well known fact: 

invmul : VG : Group.Va,fe : G.{a*b)~ l = b~ l *a _1 

where * is a notation for (op G) and for (inv G). Thanks to unification hints, we can rewrite the 
conjecture using invmul since the system knows that Z together with + and — forms the Group 3f. The 
result, however, is quite confusing: 

x,y : Z h x+x _1 *y _1 = — y 
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To understand it, it is better to de-activate the notation for group, obtaining 

x,y : Z h x + op 3f (inv i2* x) (inv 5° y) = — y 

The result is clearly correct, since (op 2f) reduces to + and (inv Sf) to — , but, until we perform the 
reduction, the notation we get is wrong. 

This problem is already extremely frequent when we use the formalization approach described in 
Section [3] and it becomes worse with nonuniform coercions, that may promote even an atomic term 
written by the user (like zplus, or +) to a richer operation, like multiplication in a group (i.e. denoted 
with *). 

A possible solution that avoids reducing the term is to overload the notation for + and — over (op 3f) 
and (inv 3f). This is usually possible since the pattern (op 3f) is more precise than the pattern (op _) 
which is matched in the generic group notation. Nevertheless, this is a bad solution for two reasons: it 
requires to declare new notations every time we define a new model of a given structure; and terms like 
(op 3f xy ) are left in the proof term where we would expect to find the simpler x+y. 

A superior solution is forcing the needed reductions, without requiring any user intervention. We 
achieve this in two steps. First of all, we change the way we declare our hints so that the term that is left 
by unification is no longer a projection of the form (op 3f), but a redex of the form 

op (Z, +,— ,assoc Sf, inv_op_cancel i^,unit_law 3?\ closed_op Sf) 

Then we change the implementation of our ITP so that redexes of this kind are automatically reduced 
as soon as they are formed. In particular, if the projection in the redex retrieves the carrier or an operation 
of the structure (like op or inv), the reduction yields the plain operation of the structure (+ or — ); if the 
projection retrieves a property, the reduction yields a projection, like assoc 3f which is a compact proof 
term for the associativity of addition. 

The strategy of reducing this form of redexes is consistent with the usually implemented one for 
/3-redexes. For example, in a system like Coq or Matita, every rewriting step with an equation a = b 
is performed by first changing the conjecture P to the j8 -redex ({Xx.P[x/a])a) and then applying the 
elimination principle for equality. The rewritten conjecture would be ((Xx.P[x/a])b), but, since /3-redex 
are immediately reduced, we obtain P[b/a]. 

The following is the hint able to generate the redexes in the case of the group of integers. Compare 
it with the similar hint given in Section |4} 

?g := (Z, +, — ,0, assoc 3f, inv_op_cancel 5°,unit_law 3f, closed.op 3f) 

op ? g = + 

It is worth observing that the expanded form of the hinted solution can obtained mechanically by 
separating fields that hold properties, that are kept as projections of the 3? structure, from fields holding 
types or operations, that on the contrary are expanded. 

It is natural to compare this approach with the alternative one consisting in implementing an ad 
hoc simplification tactic that reduces only redexes involving projections applied to concrete instances 
of a structure. While this approach does not necessarily require any deep modification to the interactive 
theorem proverj^jit has to be triggered manually and its effect is not recorded in the proof term. Reduction 
is not a proof step in CIC, thus the effect of any reduction tactic is left implicit in the resulting proof term. 
Hardwiring the greedy reduction strategy we propose in the proof engine allows to obtain proof term in 
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which the aforementioned redexes are not present. This affects in a positive way not only the type 
checking time, thanks to the smaller size of proof terms, but also the output quality of any procedure 
manipulating proof terms. 

For example in [ 10] and [6] the authors reconstruct a proof script, respectively based on a procedural and 
a declarative tactic language, starting from a proof term. Another example is (8J [7j where an explanation 
of a proof in natural language is obtained solely processing a proof term. In all these cases a proof term 
were operations are of the form (op 3f) would be clearly explained with the nomenclature of abstract 
group theory, while the original proof was carried on the concrete setting of integers, and the user did 
resort to abstract group theory only to justify some of his proof steps. 



8 Conclusions 

The most powerful tool of modern mathematics is abstraction in the following sense: the mathematical 
corpus is no longer a flat collection of facts, but a hierarchy of algebraic, topological and geometri- 
cal theories, all characterized by its own set of axioms and often very rich in models. Every concrete 
mathematical object belongs, directly or via isomorphisms, to several models and the mathematician 
effortlessly mixes lemmas from all the relative theories. 

This paper aims at making the formalization technique pioneered by Gonthier et al. ||4l |9| and the 
general machinery behind it Q run smoothly, allowing the unification heuristic of ITPs to behave in a 
more consistent way with respect to the inference of the mathematical structure a model belongs to. In 
particular, the inference is not triggered only when projections of the structure are involved in a unifica- 
tion problem, but more generally whenever a term (or type) has to be promoted to a richer structure. The 
promotion is expressed in terms of nonuniform coercions, a novel notion to the authors knowledge, that 
are shown to be implementable in terms of uniform coercions and unification hints, in an higher order 
logic equipped with dependent types and pattern matching. 
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